This is an email exchange between Paul Maley and Scott Degenhardt about using Canon ZR Times


Maley, Paul D. (JSC-DO141)[USA] wrote:

Scotty, have you come up with a good procedure for remote sites to time stamp each set of video data? 
I think you told me last time you were working on a new method. Right now I see no easy way to get 
time stamped data without depending on the camcorder internatl clock to synch properly with the KIWI 
up front and then having to do this synching again at the end. I am not partial to that kind of 
procedure. Anyway, let me know what you think.


Paul,

I haven't forgot about you on the ZR time reduction. I have attached my files as examples of my 
newest method where I use the attached AVS scipt in AVIsynth to make LiMovie display the Datecode 
(Time/Date display of the free running clock in the Canon ZR) and the Timecode (frame counter in 
the ZR that counts the incoming frames of the imaging camera) of the firewire DV AVI recording 
and I link a beginning ZR Datecode to UT and an ending ZR Datecode to UT. Then I use the attached 
spreadsheet to put in the UT time and associated ZR Datecodes and I type in (and iterate manually 
typing in) a PPM error at the bottom until I get the error to 0.0000 seconds in Column Q. This 
then gives me a straight line fit of UT versus ZR Datecode where I then can enter in any "device" 
time (ZR Datecode) for any frame in the remaining fields of the table and calculate the UT time 
associated to that frame. In the sample in the spread sheet Line 5 is my starting stamp (I call 
the reference) and Line 6 is my ending stamp. A PPM of -0.95 gave me a 0.0000 second straight 
line fit of the drift in time over the span of the start and stop times. In Line 7 I entered the 
ZR Datecode for the first frame of the DV AVI (this is when I "started observing") and in Line 8 
the last frame of the AVI (this is when I stopped observing) and got the UT time for those frames 
for my report to Brad. Then I entered in Line 9 & 10 the D and R of the event. So the Purple 
column then gives me the corrected UT time for all of these for my report. The PPM correction will 
correct for the drift of the ZR timing crystal over the span of the tape time.

Also I placed in another tab in this Excel file a tab called "tape time". This is a handy dandy 
quick calculator for locating the event on the tape once you have a reference time. I.e. if I have 
a starting or an ending UT time stamp and a ZR Datecode (or a Timecode) I can put that in the 
reference line of this page, then I put the predicted UT time of the event, and the purple area 
tells me the general place to fast forward or rewind the tape to for the event. This is particular 
calculator is not designed for accurate millisecond reduction, just a quicky estimate of where to 
find the event.

If you have any problems with this just call me and we can go over it on the phone (888-687-5444). 
My other method using strictly frame counting is very elaborate and at this point I may not even do 
that method anymore. But I have it as an alternative error check in the event of a questionable 
observation. So I won't bother confusing the issue with that at this time.

Scotty


